Temenos Lifecycle Management Suite - Origination Product Guide
Indirect Processing Overview
| Administrator Guide > Loan Origination Overview > Indirect Processing Overview |
Indirect connectors establish a secure connection between vendors and Temenos Infinity. This secure connection enables indirect vendors to transmit and receive loan application data with financial institutions.
Through the following configurations, institutions are able to customize their indirect experience:
Once an application is submitted by a vendor, it is routed by the indirect connector/channel to the Loan Origination module where an application is created. As part of the application initialization, the system uses Product Selection rules (defined by each institution) to assign a sub-product. This rule uses application conditions to assign the applications submitted to the appropriate sub-product.
 |
These conditions may include application specifics, such as:
|
The rule example illustrated below demonstrates a product selection rule that assigns a sub-product:
Queuing allows institutions to direct applications originated by an indirect source such as CUDL, Dealer Track, LSI, and RouteOne to the appropriate work queue. By establishing queuing for indirects, institutions are able to ensure applications are properly managed and reviewed by the appropriate users within a timely manner.
 |
Prior to establishing queuing for indirect applications, consider your institution's business objectives. For example, determine whether only one queue will be used for indirect applications, or whether multiple queues will be used depending on application variables, such as requested amount, vendor, application decision, and status. |
From the Queues page, create as many queues as required to meet the institution's business objective.
|
For more information on creating queues, refer to the Queuing topic within the Administrator Guide. |
Queuing rules automatically execute when a new application is created or when an application is closed in the workspace, if the application is not pinned to its current queue. These rules provide administrators with the ability to assign applications to a queue based on various conditions, such as requested amount, vendor, application decision, and status.
After all required queues have been created, queue criteria can be defined though the configuration of Queuing rules in System Management > Origination > Rules Management. The example below illustrates basic decision table that directs applications to the desired queues based on application conditions.
|
For more information on Rule configuration, please see the Rules Management topic within this guide. |
Vendor Management allows the administrator to manage a list of Vendors/Dealers with whom the financial institution does business. This list may include dealers associated with indirect application sources such as CUDL, Dealer Track, LSI, and RouteOne. The vendors within this list are used for reporting and the calculating vendor fees, such as dealer reserve.
Additionally, the Lifecyle Management Suite uses calculated Quality Scores for each vendor to grade them according to the quality of deals they submit.
|
These quality scores may be used to set review indicators to aid in decisioning. |
A system-defined Event Processing pair exists for the CUDL, Dealertrack and RouteOne connectors. This pair transmits comment to an indirect vendor when a comment is added to an application they submitted. This pairing must be activated within System Management. To activate, navigate to System Management > Origination > Event Processing. During activation, institutions have the ability to configure which comments trigger the action:
|
By default, Created in Lifecyle Management Suite with “internal” checked is selected |
When configuring the rule logic used to decision loans, institutions are able to include Vendor Quality Score types within the Decisioning rule logic. By default, the following three quality scores are included in the Lifecyle Management Suite:
| Field Name | Details | ||
| Average Credit Score |
This Quality Score provides the average Credit Score for all submitted applications for a vendor.
|
||
| Funded Credit Score |
This Quality Score provides the average Credit Score for all funded applications for a vendor.
|
||
| Funded Ratio |
This Quality Score provides a percentage based on the number of approved applications versus the number of funded applications.
|
|
Institutions are able create custom quality scores with the assistance of a Temenos Customer Care Representative. |
|
For more information on Vendor Quality Scores, refer to the Vendor Management topic within the administrator guide. |
Institutions using counteroffers to decision indirect applications, must assign the Counteroffers panel must be assigned to an Application screen. This panel enables users to create one or more counteroffers that contain alternative loan terms that are more desirable to an institution.
To assign the Counteroffers panel, navigate to System Management > Origination > Screens.
|
The counteroffers panel may only be assigned to Application screens. |
A system-defined Event Processing pair exists for the Dealertrack and RouteOne connectors that transmits counteroffer updates to an indirect vendor when a counteroffer changes. This pair ensures vendors are informed of all counteroffer term adjustments.
This pairing must be activated within System Management. To activate, navigate to System Management > Origination > Event Processing. Within the pairing, select the Active check box located on the General tab.
Institutions are able to configure the Lifecyle Management Suite to automatically create counteroffers, using a combination of the following configurations:
|
For more information, refer to the Counteroffer Configurations topic within the Administrator Guide. |
Automatic Counteroffer Rule Configurations
Within Rules Management, institutions are able to author rules which determine the countered terms and Lifecyle Management Suite behavior. Within the Event Processing category, rule authors are able to define the behavior of automatic counteroffers using the following action templates:
| Template | Description | ||
| Create a counteroffer | This template enables institutions to define the interval in which countered loan terms and amounts should increase or decrease. | ||
| Create a counteroffer for manual review | This template enables institutions to define the loan terms and amount of the counteroffer. Upon generation, each counteroffer is flagged for underwriting review. | ||
| Set counteroffer priority |
This template enables institutions to define which loan term should be prioritized when creating counteroffers.
|
||
| Add a comment to a counteroffer | This template enables institutions to add comments to a counteroffer. | ||
| Add a stipulation to a counteroffer | This template enables institutions to add stipulations to a counteroffer. |
For more information on authoring rules using these action templates, see the Rules Management topic.
Automatic Counteroffer Event Processing Configurations
Once rules have been authored, create Event Action pairings to tie the automatic counteroffer rules to triggering events.
Within the Events tab, select an event that triggers the automatic counteroffer rules to process, such as: Field Changed > Application Status.
Automatic Counteroffer Solution Parameters
Once rules and event action pairs have been defined, navigate to the System Management > Modules > Origination, and select the System tab.
Update the following parameters to define the behavior of automatic counteroffer processing:
| Parameter | Description | ||
| Indirect Application Counteroffer Decision Notification |
Allows institutions to indicate how the system communicates counteroffers to indirect connectors. Within this parameter, the following options are available:
|
||
| Automated Counteroffer Maximum Iterations |
Allows institutions to indicate the maximum number of iterations that each automated counteroffer action type should attempt.
|
The Promotions functionality provides institutions with an easy and efficient method of creating and managing promotion campaigns in Temenos Infinity, which include pre-approved offers uploaded directly to each promotion.
If desired, institutions can create promotional offers for one or more sub-products tied to indirect applications. During the decisioning process, the system then determines if a new indirect application matches an existing promotional offer, automatically accepts or declines the offer based on rule criteria, and links the new application to the offer when the offer is accepted.
The following configurations are required to link an indirect application to an available promotion during the decision process:
From the Promotions page in System Management (System Management > Origination > Promotions), system administrators are able to configure the promotional offers available for an institution, and assign the promotion to one or more loan application types that are associated with indirect applications.
|
For a complete overview of how to create and manage promotions, please see the Promotions topic in this guide. |
In Rules Management (System Management > Origination > Rules Management) , system administrators can author rules to execute during the decisioning of an indirect application to determine if the application matches an existing promotional offer, and automatically accept or decline the offer based on rule criteria.
System administrators can author a rule using an If...Then, or If...Then...Else statement, to define the conditions for a promotional offer, and then accept or decline the offer based on the conditions being met.
Reference the table below for an overview of the Rule Category, Entity, and Action Templates to use when authoring Promotion rules for indirect applications:
| Rule Category | Entity | Action Templates |
| Promotions | Promotions |
Accept Promotion Offer Decline Promotion Offer |
The following example displays a rule authored to accept a promotional offer based on the value of the Sub-Product and Offer Amount in the application:
|
There are many ways to author a rule; therefore, the image below should be used as an example ONLY. |
When the above configurations are made, and an application including a Source of Call Center or Indirect is decisioned, the system executes the rules configured under the Promotions category to determine if there are any active promotional offers associated with the primary applicant’s TIN that have not been accepted or declined. If an offer is found, the system automatically accepts or declines the offer based on rule criteria.
|
This Decisioning logic executes prior to Credit Report Processing. |
When a promotional offer is accepted for an indirect application, the Offer Decision Status is set to Accepted, and the promotion is linked to the application.
|
If there are multiple promotions associated with the application, the system automatically accepts the first offer returned for the application. |
Once an offer is accepted, the Application > Channel field is set to a value of PROMOTION, the Created By field is set to the name of the indirect user, and the system populates the following Application fields with data from the promotion:
|
The value of the below fields is automatically set by code when an application is created for a promotional offer; therefore, the fields are read-only when configured to appear in an Application screen.
|
| Application Field Populated | Value Set To From Promotional Offer |
| Application > Matched Promotion > Promotion Name | Name of the promotion. |
| Application > Matched Promotion > Offer ID | Offer Id of the promotion. |
| Application > Matched Promotion > Offer Amount | Amount of the promotional offer. |
| Application > Matched Promotion > Offer Term | Term of the promotional offer. |
| Application > Matched Promotion > Offer Rate | Rate of the promotional offer. |
| Application > Matched Promotion > Offer Decision Status | Decision Status for the promotional offer. |
The system then continues with the decisioning process, based on the Decision Status configured for the promotion.
|
If an account decision is required for the application, the system proceeds with the account decisioning process once the loan is approved. |
|
For more information on creating applications from Promotional Offers, please see the Promotions topic in the User Guide. |
A system-defined Event Processing pair exists for the CUDL, Dealertrack, and RouteOne connectors that transmits application updates to an indirect vendor when the following application events occur:
This pairing must be activated within System Management. To activate, navigate to System Management > Origination > Event Processing. During activation, institutions have the ability to configure which field changes trigger the action. The available fields include:
|
If Buy Rate, Contract Rate, Final Loan Amount, Interest Rate Actual, Term, or Total Fees In Loan Amount triggers the action, hardcoded logic prevents the decision from transmitting if the Decision Status has a value of None or Null. Additionally, If Status Id triggers the action and the new application status is IN_PROGRESS, PENDING_REVIEW, DECISIONED, NOT_ELIGIBLE, WITHDRAWN, or AUTO_WITHDRAWN the action is cancelled. |
During the application lifecycle, information may periodically updated to identify the contract status and assure that the system mirrors what was included in the purchase contract.
Upon the arrival of the dealer contract, it is advised that institutions update the Temenos application to match the amounts agreed upon within the dealer contract. Therefore, it is advised that an Application screen is created with:
Once created, the application screen should be assigned to the Approved category in the Workflow.
|
For more information on indirect contract updates, refer to the Contract Updates topic within the User Guide. |
During the post-decision process, the Dealertrack and RouteOne connectors are able communicate the Indirect Contract Status as well as the dates and time the contract status changes. It is advised that an Application screen contains the fields that track the indirect contract status. The following fields are available for Application screens:
These dates are updated, when the end user updated the Indirect Contract Status Id field. Refer to the following table for contract status descriptions:
| Status | Description |
| Received | The Dealer Packet has been received by the institution. |
| Held | The institution is holding the Dealer Packet, but is not distributing funds to the dealership. |
| Re-Approved | The Dealer Packet has been reviewed and approved, but funds have not been distributed. |
| Rejected | The Dealer Packet has been reviewed, but information is incorrect and the dealership must resubmit a corrected Dealer Packet. |
| Funded | The Dealer Packet has been reviewed and approved. Funds have been disbursed by the institution. |
During the post decision process, institutions are able to identify the dealer reserve amount that is distributed to the indirect vendor that originated the loan. The dealer reserve amount is either manually entered or calculated automatically by one of the following calculations:
| Vendor Fee Type | Calculation |
| Split Percentage | (Lending.Loan.TotalInterest (Contract Rate) – BuyRateTotalInterest) * Application.VendorSplit |
| Vendor Percent of Interest Accrued | Lending.Loan.TotalInterest * Application.VendorFeePercentage * 0.01 |
| Vendor Percent of Loan Amount | Loan.FinalLoanAmount * Application.VendorFeePercentage*.01 |
| Vendor Percent of Amount Financed | Application.AmountFinanced * Application.VendorFeePercentage*.01 |
| Vendor Flat Fee | Defaults to Application.VendorFlatFeeAmount |
| Vendor Flat Rate | Loan.FinalLoanAmount * Application.VendorFlatRate |
| Manual | No calculation is run for this type |
| Buy Down |
Greater of the following:
|
If the Vendor Fee Amount is greater than $0.00, the funds are automatically allocated to the designated GL Voucher. The user is not required to manually select the Dealer Reserve GL during Funding.
Institutions are able to perform the following configurations to ensure the calculated values meet the vendor agreements:
|
The aforementioned vendor fee calculations are also determined based on the loan amount and rate values that were updated within the Loan Contract Update Screen. |
When performing the aforementioned calculations, the Lifecyle Management Suite uses the following variables that are set by the institution. These variables are set using the following solution parameters within the System tab in the Origination page in System Management:
| Parameter | Description |
| Vendor Split | This parameter specifies the percentage that the dealer receives from a given application. |
| Flat Rate | This parameter specifies the flat rate that the dealer receives from a given application. |
The Vendor Fee Type field is linked to a system lookup titled VENDOR_FEE_TYPE, which is configured with the following system-defined values:
By navigating to System Management > Origination > Field Configurations, institutions are able update the following Vendor Fee attributes:
| Vendor Fee Attribute | Description |
| Description | The description of each lookup value populates within the drop-down list associated with the Vendor Fee Type field in an application. |
| Vendor Fee Amount Editable |
Allows an institution to determine if users are able to override the calculated amount for specified vendor fee types.
|
When dealer contracts are received by institutions, they may include GAP and MBD products. As result, institutions using the Dealertrack and RouteOne connectors require rules to be authored which pitch GAP and MBD cross-sell products in the amount of $0.00.
|
GAP and MBD transmit as fees for applications submitted by CUDL vendors. |
Once a contract is received, users are able to navigate to the Cross-sells screen and update the $0.00 amounts to reflect the value of the plans purchased at the dealership.
To author these rules, navigate to System Management > Origination > Rules Management and select wither the CrossSellProducts, Decisioning, or EventProcessing rule category.
|
The CrossSellProduct category allows institutions to pitch GAP and MBD with every Dealertrack application. The Decisioning and EventProcessing categories allow institutions to author rule logic that pitches GAP and MBD on approved applications. |
Each approved application must contain both a Member Account Number and a Loan Account Number. Using Event Processing, institutions are able to configure a pairing that automatically generates new account numbers for applications.
Configure an Event Processing pair to automatically create new member account for non-member applications
Configure an Event Processing pair to automatically generate the next available suffix.
Within the FEE_CODE lookup, institutions are able to identify whether a Fee should be included in the Final Loan Amount that is disbursed to the Third Party vendor. If a Fee Code is identified as Exclude From Third Party, the corresponding amount is deducted from the Final Loan Amount. This functionality enables institutions to ensure internal fees, such as New Account Vouchers, are not transmitted to indirect vendors.
|
This functionality is only available in applications transmitted with the Dealertrack and RouteOne connectors. |
The funds associated with each approved application must be allocated to the proper individuals. Using rule logic, institutions are able to author Event Processing rules that ensure funds such as Dealer Reserve, Fees and Vehicle Purchase Price are distributed properly. Using the Add a GL voucher funding record to a Loan and Add a Check funding record to a Loan rule templates, institutions are able to automate the allocation of loan proceeds to vendors
Using the Add a Check Funding Record to a Loan action template, rule authors are able to create check loan allocations by determining specific allocation amounts, payees, and memos. Additionally, this template gives rule authors the ability to exclude payees from OFAC.
|
For more information, refer to the Add a Check funding record to a Loan rule template example. |
Using the Add a GL Voucher Funding Record to a Loan action template, rule authors are able to create general ledger loan allocations that include an allocation amount, as well as destination general ledger.
|
For more information, refer to the Add a GL voucher funding record to a Loan rule template example. |
When an application is disbursed, a system-defined Event Processing pair titled "CUDL, Dealertrack, and/or RouteOne Disbursement Update" transmits the dates and status within the indirect connector when the application is disbursed. This information allows vendors to identify when funds and fees can be expected.
This pairing must be activated within System Management. To activate, navigate to System Management > Origination > Event Processing. Select the Disbursement Update pair. Within the pair, select the Active check box located on the General tab.